其他
嵌入Python解释器的程序逆向
一
前言
二
为什么无法搜索内存改值?
简单的说,就是 Python 的值打一枪换一个地方,所以 CE 这种搜固定内存的变化的方法是很难直接找到对应的值进行修改的。你可以自己启动 Python,输入 a=1234, 用 CE 搜索,再输入 a = a+1,再用 CE 搜索,是搜不到任何对应内存的。
下面我用一段官方的示例代码(https://docs.python.org/3/c-api/intro.html#coding-standards),来说明一下。这段 Python 代码和 C 代码是等价的,用于将 dict[key] 自增 1.
try:
item = dict[key]
except KeyError:
item = 0
dict[key] = item + 1
incr_item(PyObject *dict, PyObject *key)
{
/* Objects all initialized to NULL for Py_XDECREF */
PyObject *item = NULL, *const_one = NULL, *incremented_item = NULL;
int rv = -1; /* Return value initialized to -1 (failure) */
item = PyObject_GetItem(dict, key);
if (item == NULL) {
/* Handle KeyError only: */
if (!PyErr_ExceptionMatches(PyExc_KeyError))
goto error;
/* Clear the error and use zero: */
PyErr_Clear();
item = PyLong_FromLong(0L);
if (item == NULL)
goto error;
}
const_one = PyLong_FromLong(1L);
if (const_one == NULL)
goto error;
incremented_item = PyNumber_Add(item, const_one);
if (incremented_item == NULL)
goto error;
if (PyObject_SetItem(dict, key, incremented_item) < 0)
goto error;
rv = 0; /* Success */
/* Continue with cleanup code */
error:
/* Cleanup code, shared by success and failure path */
/* Use Py_XDECREF() to ignore NULL references */
Py_XDECREF(item);
Py_XDECREF(const_one);
Py_XDECREF(incremented_item);
return rv; /* -1 for error, 0 for success */
}
关注其中
incremented_item = PyNumber_Add(item, const_one);
在获取到item
后,并不会直接对item
内部的内存进行自增,而是调用函数进行加法,创建了一个新的对象incremented_item
,然后再PyObject_SetItem(dict, key, incremented_item)
换回去。所以两个值在内存上并不会是同一个地址。另外,注意其中
Py_XDECREF(item);
这是减少一次引用计数的意思。python 底层实现里 PyObject 都是有引用计数的。这也意味着我们如果直接修改内存中的值,会同时修改所有使用这个对象的地方。所以,最好的方法还是在 Python 解释器以及前面的字节码这部分把问题解决掉,而不是在内存里解决。
三
通过 hook 解释器底层函数来修改值
没法直接搜特征,所以只能对照着源码的字符串,去定位一些关键函数。这个步骤就和做数独一样。
个人感觉hook后能够获得大量信息的函数有
PyUnicode_FromString, _PyObject_GenericGetAttrWithDict, PyObject_SetItem, PyObject_Call
。还有一些有用的辅助函数有PyObject_Repr, PyUnicode_AsUTF8, PyGILState_Ensure, PyGILState_Release
Python36-x64\include\Python.h
,虽然不能直接用自己这个 Python 解释器里的函数,但是头文件里很多宏是对对象直接操作的,还是比较有用的。hook 之后如何获取运行信息呢?PyUnicode_FromString 的参数就是 const char * ,直接打印就好。但是其他几个参数都是 PyObject,所以我们需要把 PyObject转为可读的字符串,以便进行进一步的分析。
利用嵌入的 Python 解释器自己的 PyObject_Repr 和 PyUnicode_AsUTF8 就可以获得可读信息。下面是我用的代码。
函数地址是嵌入的 Python 解释器对应函数的地址。有些对象可以直接用自己下载的那个解释器的函数,应该是字符串对象这种不需要执行具体指令的对象。但是其他对象很容易崩。
{
//auto gstate = oPyGILState_Ensure();
//auto pyobj = reinterpret_cast<PyObject*>(obj);
auto str_obj = oPyObject_Repr(obj);
if (!str_obj) {
PyErr_Print();
//oPyGILState_Release(gstate);
return {};
}
const char* str = oPyUnicode_AsUTF8(str_obj);
if (!str) {
PyErr_Print();
Py_DECREF(str_obj);
//oPyGILState_Release(gstate);
return {};
}
string ret{ str };
Py_DECREF(str_obj);
//oPyGILState_Release(gstate);
return ret;
}
因此,有些对象不方便用这种方法获取可读信息,就可以只获取其类型信息,用
string obj_class = Py_TYPE(obj)->tp_name;
。同时,尽量减少查看的类型,过滤不感兴趣的调用可以有效减少崩溃。下面是对 _PyObject_GenericGetAttrWithDict 的 Hook 示例。
static unordered_set<string> intersted_name{
R"#('m_HP')#",
};
ostringstream oss;
auto name_str = GetPyObjectString(name);
if (intersted_name.find(name_str) == intersted_name.end()) {
oss << "Skip: "<<name_str;
LogMsg(oss.str());
return o_PyObject_GenericGetAttrWithDict(obj, name, dict);;
}
string obj_class = Py_TYPE(obj)->tp_name;
oss << "_PyObject_GenericGetAttrWithDict: " << endl
<< '\t' << obj <<":" << obj_class << endl
<< '\t' << name << ":" << name_str << endl
<< '\t' << dict << endl;
// 避免被回收,提前解析字符串
auto ret = o_PyObject_GenericGetAttrWithDict(obj, name, dict);
auto dict_str = GetPyObjectString(ret);
auto t = Py_TYPE(ret);
oss << '\t' << " -> " << ret << " Type: " << t->tp_name << " Value: " << dict_str;
if (obj_class == "Player") {
if (name_str == R"('m_HP')") {
((PyLongObject*)ret)->ob_digit[0] = 78900; // 血量
oss << " hijked -> " << ret << Py_TYPE(ret)->tp_name << " : " << GetPyObjectString(ret);
}
}
LogMsg(oss.str());
return ret;
}
((PyLongObject*)ret)->ob_digit[0] = 10000;
设置。这样直接改存储值其实不好,一方面所有用同一个对象的地方都会被修改,一方面存储0这样的常量的地方是改不了。更好的做法是像 Python 那样新建对象、设置对象、减少引用。但无所谓,现在玩家的 m_HP 已经在 Python 解释器层面无法被减少了。
四
改值之外?
PyObject_Call 能够监听很多东西。看日志发现程序导入 zlib,从一个特殊格式的文件里读入信息,并进行解压。解压后立即进行了模块导入。看解压的内容,'\33\r\r\n'刚好是 Python36 字节码的 MaigcNumber。可以推断这是实际运行的业务代码。类名、函数名都是能够从字节码里还原出来的。
根据日志的 PyObject_Call 看到嵌入的解释器能够直接导入该字节码的。
一方面可以试试纯用 Python C API 接口,例如
PyObject_Dir
在嵌入的解释器里查,但是这样逆向写起来实在算不上方便;PyRun_InteractiveLoop
调出交互命令行来,这样应该更加方便。还有纯逆向直接调用 PyObject_Call,但是想想都觉得很麻烦。
如果接下来想要获得更大的自由度,应该考虑看一看 Python 字节码层面。直接摆弄解释器还是太底层了。
五
结论
看雪ID:mb_fefksfsl
https://bbs.kanxue.com/user-home-979936.htm
# 往期推荐
1、记由长城杯初赛Time_Machine掌握父子进程并出题
5、Attitude Adjustment -- Fast Quaternion Attitude
球分享
球点赞
球在看
点击阅读原文查看更多